I understand this is for security reasons, but it does make me wonder about the implications. Theres a few scenarios where applications installed elevated still write to user scoped registry keys, but require elevation to fully uninstall because they wrote their data to Program Files instead of a location accessible by a non-elevated context.

In a similar vein, many everyday users have a misconception that anything they can do non-elevated, they should also be able to do elevated. If a user can uninstall a package to the user scope while not elevated, the likely expect to be able to uninstall it elevated too. Granted the messaging and error will help address that case.

Or, if a user can install a package to the user scope while elevated, then why is removing it from the machine scope while elevated prohibited? Which brings the question - why is this this limited only to uninstall?

Nothing about these comments should block the PR, would just like some additional perspective from the team and/or @denelon on this, since such a strong move seems like it will have a negative impact on the users of WinGet, and may even be breaking for some packages

Or, if a user can install a package to the user scope while elevated, then why is removing it from the machine scope while elevated prohibited? Which brings the question - why is this this limited only to uninstall?

It isn't, repair already has the same check. Do you mean why is installed allowed for instance? Writing isn't an issue, reading is.

The better solution long term would be to write code to launch an unelevated process, then have these become invoking that path.